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Chapter 1 

Methodology for Integrating Air Traffic Simulation 
Models 


Introduction 

The National Aeronautical and Space Administration (NASA) is undertaking an 
ambitious program in advanced air traffic management (ATM) research to ex- 
plore, test, and demonstrate 21st-century technologies required to enable safe and 
efficient air travel. With significant changes expected in technologies, ATM pro- 
cedures, and roles and responsibilities of various interested parties, it is necessary 
to construct a modeling and simulation infrastructure to explore the multidimen- 
sional performance of proposed concepts and system changes. 

LMINET is a queuing network model of the entire National Airspace System 
(NAS) developed by LMI for NASA [1,2,3, 4], Presently, LMINET is implemented 
at 64 airports (Figure 1-1).' These airports account for approximately 85 percent of 
domestic commercial air transport enplanement and more than 80 percent of air 
carrier operations. The LMINET airports are a superset of the Federal Aviation 
Administration’s (FAA’s) 57 pacing airports in air traffic studies. 

In general terms, LMINET models flights among a set of airports by linking 
queuing network models of airports with sequences of queuing models of the 
Terminal Radar Approach Control (TRACON) and Air Route Traffic Control 
Center (ARTCC) sectors. Based on the solutions of the analytical queuing equa- 
tions, LMINET offers a fast simulation mode of the NAS. Because the network 
effect of the delays are considered for the moving aircraft, it is a valuable air traf- 
fic simulation model for a national air traffic study. 

The Total Airspace and Airport Modeler (TAAM) and SIMMOD are two widely 
used simulation models of airport and airspace with varying degrees of sophisti- 
cation [5,7]. These event-driven simulation models consider all aircraft operations 
second-by-second. A high degree of fidelity is achieved with TAAM or 
SIMMOD; thus, these models are more accurate in generating the air traffic sta- 
tistics. Appendices A and B provide brief introductions to TAAM and SIMMOD, 
respectively. 


, The 64 airports, by ilicn codes" are ABQ. AT... Al'S. BDL. BNA. BOS. BUR. BWL OLE. (XT. CMH. CV(i. DA... DAY. DCA. DEN. DFW. 

DTW. KLP. F.WR. ELI.. (ISO. HOI'. HPN. 1AD, I AH. INI). ISP. IKK. IAS. LAX. UiA. LOB. MOL MO). MDW. MEM. MIA. MKE. MSP. MSY. 
OAK. ONT. OKI). PBI. PDX. P1IL. PHX. PIT. RIX'. RNO. SAN. SAT. SOF. SEA. SFO. SJO. SIX'. SMI . SNA. STL. SYR. TLB. and TPA. 
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Figure 1-1. LMINET Airports 



Because TAAM and SIMMOD must consider every detail of an aircraft opera- 
tion, building a model tor an airport or an airspace takes a long time. The data and 
effort required to develop network versions exceed the resources available for 
most studies. 

This report details the results of a feasibility study for integrating LMINET with 
TAAM and SIMMOD. The perceived benefits of such integrated models are two- 
fold: With a high-fidelity TAAM or SIMMOD model to substitute for a local 
model in LMINET, we improve the accuracy of reported air traffic statistics for 
the NAS. With LMINET regulating the demand to an airport modeled by TAAM 
or SIMMOD, the demand to the airport better reflects the network effect of the 
NAS and the reported air traffic statistics at the airport will be more accurate. For 
this project, we performed the following tasks: 

1. Propose the model integration methodology. 

2. Demonstrate the feasibility of the model integration. 

3. Demonstrate the benefit of the integrated simulation. 

4. Identify issues for a full-blown integrated model. 
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Integration Methodology 

In an integrated air traffic simulation model, although we may be interested only 
in air traffic statistics and delays reported in specific areas or for the whole sys- 
tem, the entities being modeled are moving aircraft, which result in inter-related 
air traffic demand. The general methodology of an integrated air tiaffic simulation 
model is depicted in Figure 1 -2. This figure is a general schematic at the concep- 
tual level, where the individual models can take any form from LMINET, to 
TAAM and SIMMOD, or any other simulation models, regardless of the simula- 
tion methodology and data requirements. Before the start of the simulation, one 
should prepare the initial flight schedule files for all of the models involved and 
initialize the system state and the various statistic counters. The initial flight 
schedule file can be based on the published schedule, which is a place-time table 

that barring any disturbances resulted from bad weather, mechanical failure, 

airport or airspace congestion, and so forth — all aircraft will meet. Although the 
physical computer schedule files are created by convenience of management (e.g., 
a schedule table for all models), there should be a separate schedule file for each 
air traffic management entity conceptually (i.e., airport or airspace). 

Figure 1-2. Schematic of General Integrated Simulation Models 
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Simulation models will be run at one time unit at a time, typically for a few repre- 
sentative days. Because most commercial flight schedules repeat daily, we must 
run the model for a whole day. The daily difference in schedules can be analyzed 
by running the schedules for different days. At the end of each simulation epoch, 
the delays are computed and are fed to modify each schedule file in the integrated 
model. Aircraft delays and schedule modifications are the only link between the 
models. LMINET, which is an air traffic simulation model of the entire NAS, is 
actually modeled in this fashion. Within LMINET, 64 aiiport delay models and a 
couple of hundred airspace delay models run simultaneously within each time ep- 
och (one hour); at the end of each epoch, the delays are computed and are fed to 
schedule files of each airport and air traffic control sector to modify the schedule 
tor the rest of the day. Constructing the aircraft schedule file is much less time- 
consuming than building other parts of the model for TAAM and SIMMOD, so 
integrating LMINET with TAAM or SIMMOD is a quick way to gain the benefit 
of both models. 

Although TAAM and SIMMOD take detailed consideration of aircraft operations, 
the aircraft interactions considered are all within the perimeter of the model (e.g., 
an airport). As outlined by our general methodology, the interaction of aircraft 
operations outside the perimeter of the model is through modification of aircraft 
schedules. TAAM and SIMMOD cannot be run interactively, or they can be run 
only in the batch mode that the models run the simulation through once the 
schedule is given. One cannot modify schedule files even for flights that occur 
before the system clock. Thus, TAAM and SIMMOD must be stopped at the end 
of each epoch in order to collect delays and modify the schedules for the rest of 
the day. Worse yet, TAAM and SIMMOD can have only a “cold start” — that is, at 
the beginning of the each simulation model, the airport is assumed to be com- 
pletely empty. If we assume the schedule is fixed for an air traffic simulation at an 
airport , “cold start” is a reasonable assumption if one uses the model to simulate 
air traffic on a day that typically starts in the early morning when air traffic de- 
mand is nonexistent or close. “Cold start” rules out another possibility of running 
the model at a time with the most current schedule but with the system state at the 
beginning of the epoch the same as at the end of the previous epoch. 

Our proposed approach to circumvent “cold start” and the rigid schedule files in 
TAAM and SIMMOD is the Progressive Augmented Window (PAW), depicted in 
Figure 1-3. Under PAW, the window or period of the simulation is successively 
increased until the end of the time clock is reached. After initialization of the 
system clock, the simulation begins. At each iteration, all of the simulation mod- 
els will be run from the beginning of the day (epoch 0) through the current time 
epoch. At the end of each iteration, delay statistics are collected and fed to modify 
the schedules. The window of the simulation will successively increase until it 
covers the entire day in the last iteration. One can see that PAW avoids “warm 
start” and the rigid schedule file structure in TAAM and SIMMOD, yet it properly 
considers the delay impact in the network. The expense of PAW is that we have to 
repeat the simulation of all previous epochs to run the simulation models for the 
current epoch. This iterative process wastes considerable computer resources. We 
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Methodology, for Integrating Air Traffic Simulation Models 

believe however, that this methodology is the only one that will enable us to have 
an integrated LMINET-TAAM or LMINET-SIMMOD model, given the current 
versions of TAAM and SIMMOD. 

Figure 1-3. Schematic of Progressive Augmented Window Approach 
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Simulation Settings 


The following settings were used in the feasibility study. 

♦ Period of simulation. The integrated simulation involves a total of 2 1 
simulation epochs, starting at 6:00 a.m. Eastern Standard Time. Each ep- 
och lasts one hour; the period of operation covered is 6:00 a.m. through 
2:00 a.m. the next day. There is hardly any traffic from midnight to 

6:00 a.m.; thus, the period of simulation will give us enough time to cover 
the time differences in the United States and lingering delays at the end of 
the day. 

♦ Schedule selection. The airline schedule published by the Official Airline 
Guide (OAG) for June 19, 1997, plus representative General Aviation 
(GA) flights is used for LMINET. Air traffic demand from other airports 
to the LMINET network also is included; this demand, however, is con- 
sidered isolated and does not have any network effect. The TAAM sched- 
ule file is also derived from the same OAG schedule. A similar 
representative design schedule is created for SIMMOD, which also is 
based on a summer day OAG schedule in 1997 adjusted for GA traffic. 
The time and funding of this project do not allow us to create another 
SIMMOD schedule file; we had to use the SIMMOD model built for an- 
other task. For practical purpose, the schedule in SIMMOD model is the 
same as in LMINET. Maintaining the consistency of the schedule files for 
the different models is absolutely essential to have valid simulation results 
because we must ensure that the schedules deal with the same moving air- 
craft. 

♦ Simulation models. A TAAM model at Dulles International Airport (IAD) 
and a SIMMOD model at Chicago O’Hare International Airport (ORD) 
were selected for an integrated LMINET-TAAM and LMINET-SIMMOD 
feasibility study, respectively. Because the airspace delay is negligible for 
the total delay in the NAS under good weather conditions reported by 
LMINET, we omit the airspace delay model runs in LMINET for the inte- 
grated study without jeopardizing the validity of the feasibility study [3,4], 
Including airspace delay models in LMINET requires more effort and 
much more computer time to execute LMINET. 

♦ Simulation weather. The actual weather of the NAS for April 8, 1996, is 
selected. During that day, the NAS enjoyed generally good weather, 
except isolated bad weather for a few hours in Boston, Seattle, and San 
Diego [3,4], Our TAAM model at IAD and SIMMOD model at ORD 
assume good weather conditions throughout the day. 

♦ Collection of delay statistics and modification of schedule. LMINET can 
generate the average delay for all departures and arrivals during each ep- 
och at each LMINET airport; TAAM and SIMMOD can generate delay 
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statistics for each aircraft, as well as average delays. For the feasibility 
study, we have considered only average delays reported by LMINET, as 
well as by TAAM and SIMMOD. We did not take full advantage of delay 
reporting by TAAM and SIMMOD, for this feasibility study. Although 
LMINET uses the schedule only in terms of aggregate demand for an ori- 
gin and destination pair within one time epoch, assignment of delays to 
flights to the TAAM or SIMMOD airport is still possible if all of the 
schedules used by LMINET, TAAM, or SIMMOD are based on the same 
schedule. This is why it is so important to use the same schedule to derive 
the schedule files. 
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Chapter 2 

Integration of LMINET with a TAAM Plus 
Simulation Model at Washington Dulles 
International Airport 

Introduction 

LMINET is capable of scaling the traffic level of the entire NAS and deriving na- 
tional schedules. TAAM is capable of very detailed simulations in local areas 
such as TRACONs or traffic corridors and producing realistic delay measure- 
ments. If the two models could be used in tandem, sharing data, the integrated 
whole would be capable of producing detailed local results and commensurate 
national traffic levels. 

In this chapter we discuss the process we used to integrate TAAM and LMINET, 
TAAM preprogramming, the challenges and issues in integrating the models de- 
mand files and our resolution of those issues, and a flight delay comparison re- 
sulting from TAAM simulation runs. 

Integration Process 

Integration is being attempted in small steps. For this first project, we first identi- 
fied inputs and outputs needed to flow between LMINET and TAAM. Because ol 
the nature of each model, we determined that LMINET and TAAM should be run 
in turns, sharing data, so that the models develop “agreement” on delay and traffic 
levels. For example, LMINET will be run on a traffic demand file, determine na- 
tional delay levels commensurate with that demand, then adjust the number of 
flights and flight times to reflect an acceptable level of delay. One or more hours 
of LMINET-adjusted flight times (from a limited area of the country) can then be 
run in a detailed TAAM simulation. TAAM will determine per-flight delays for 
that area, taking into account current runway capacity, technological enhance- 
ments available in that area, and the interaction between flights caused by air- 
space constraints. Given a newer and more locally accurate level of flight delay 
for a given area, LMINET can recalculate the day’s schedule. Because LMINET 
calculates schedules one hour at a time, we decided to proceed by iterating sched- 
ules and delay data one hour at a time. This iterative process transfers data be- 
tween the two models as follows: 

1 . Appropriate set-up data are input into both models. 
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2. An LMlNET-generated flight file is processed to produce a TAAM input 
flight file. 

3. TAAM is run for the first hour of the day; resulting delay data are fed into 
LMINET. 

4. LMINET generates a new flight file, which is processed to produce a 
TAAM input file. 

5. TAAM is run for the first two hours of the day; resulting delay data are 
fed into LMINET. 

6. And so on. 

To achieve this iteration between the models, several capabilities must be demon- 
strated and tested. 

Model Preparation: 

1 . Create a bug-free local area simulation in TAAM 

2. Reduce OAG for input into LMINET 

3. Establish dial-up or co-host connection between TAAM and LMINET 
ITERATION; 

4. LMINET read-in demand from OAG 

5. LMINET generates a flight schedule with acceptable levels of delays for 
desired technology set 

6. Inter-model processing program takes the LMINET flight schedule as in- 
put. manipulates it, and outputs a TA AM-acceptable demand file 

7. New flight schedule sent to TAAM and loaded into existing simulation 

8. TAAM simulation run 

9. Inter-model processing program reads TAAM output files (*.rep, *.hst, 
*.msg) and outputs hourly per-flight delay for relevant flights and number 
of cancelled flights 

10. Results of step 9 input into LMINET 

1 1. LMINET generates second demand file 
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Integration of LMINET With a TAAM Plus Simulation Model at I AD 

Derivation Of Traffic Day: 

12. Repeat steps 5-11. 

Considerable work underlies preparation of a bug-free TAAM simulation; some 
of that work is detailed in Appendix B. A brief overview is provided in the fol- 
lowing section. 

Programming TAAM Plus 

We used the TAAM Plus simulation model, version 1.1. TAAM is an airspace 
modeling tool that can simulate all domains, from gate and taxiway movements 
through takeoff, climb-out, separation conflicts, and separation strategies. It is an 
aircraft characteristic-based, time-step emulation model that is ideal for detailed 
flight path modeling. 

We modeled the Dulles terminal airspace in great detail, including actual air traf- 
fic control sector shapes, nearby airports, and all scheduled traffic flows through 
the area. Because of the short time allotted for this project, we did not model the 
ground layout of Dulles beyond the runways; there were no taxiways or gates in 
this simulation. 

Programmed inputs included the following: 

♦ Dulles International (IAD), Reagan National (DCA), and Baltimore- 
Washington International (BWI) airports 

♦ Standard Instrument Departures (SIDs) and Standard Terminal Arrival 
Routes (STARs), issued October 6, 1999 

♦ Configuration and runway usage tiles from Potomac TRACON 

♦ OAG flight data 

Great detail went into programming Dulles STARs and SIDs. A STAR is the arri- 
val path an aircraft takes through the terminal area, from as much as 250 nautical 
miles away from its destination down to the runway touchdown. SIDs are defined 
routes that aircraft must follow when they exit a terminal area before entering the 
cruise portion of their flight. Most holding and maneuvering is made during the 
SID or STAR portion of the flight. 

We were careful to preserve the separate routes used by jets, pistons, and turbo- 
props. At least one STAR and SID must be programmed for each runway to ac- 
cept traffic from each arrival fix or feed traffic to each departure fix. Where there 
are three runways in use at an airport, we programmed three SIDs — one for each 
departure fix from that runway — and three STARs to route aircratt to the proper 
runway. To model more than one configuration (e.g., south operations and north 
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operations), new sets of STARs and SIDs must be programmed for each configu- 
ration. Some time can be saved if a particular runway never accepts jets or never 
accepts turboprops. In those cases, there is no need to program the instructions to 
bring that type of aircraft to and from the runway. 

We mapped the endpoints of SIDs and STARs in use for each airport in each 
simulation. We sorted the route file for all flights to and from each airport and 
listed the endpoints of each route. A great deal of programming time was spent to 
ensure that endpoints of routes matched the endpoints of SIDs and STARs; oth- 
erwise, TAAM sends aircraft on a “default” approach or departure. These “de- 
faults” generally contravene a terminal’s standard operating procedures and 
would render our careful terminal modeling useless. In most cases, we changed 
the route file, adding arrival fixes and departure gates; in some cases, we found 
that there were no defined STARs to bring in a little-used route. In those cases, 
we composed STARs on the basis of controllers’ flow diagrams, radar pictures, 
and standard operating procedures. Most STARs and SIDs for an airport resemble 
trees in that all the routes converge on a final pattern to or from a runway end, so 
there is very little guesswork involved in programming a new SID or STAR. 

Separate STARs were programmed for instrument meteorological conditions 
(IMC) operations because operations in that visibility require a 12-mile final ap- 
proach. Not all runways are open under IMC; IMC STARs and SIDs were not 
programmed for non-open runways. 

Jets and props were instructed to fly at different altitudes, using the demand file. 

In the terminal environment, turboprops generally fly 2,000 feet lower than jets on 
the same route. There are some exceptions; in particular, slow or underpowered 
jets sometimes will be routed on the turboprop route, and very high performance 
turboprops can travel along jet routes if they prefer (when congestion is lighter on 
that route). For example, jets and turboprops arriving to a terminal and entering a 
“mixing area” often will be sent over or under crossing traffic; high-performance 
aircraft generally go over (at 8,000 feet or above); lower-performance aircraft go 
under (at 4,000 feet). An aircraft’s ability to execute steep arrival slopes deter- 
mines which path it will be directed to. This performance capability is identified 
in TAAM's aircraft characteristic file. 

The Potomac TRACON modeling group began a convention of creating separate 
routes for turboprops, jets, and pistons — distinguished by a “.J” or “.P” or “.T” 
after the route name. For example, the route between Dulles and Orlando gener- 
ally is called KIADKMCO; the Potomac group has created a new route file in 
which there are three routes for the same flight: 

♦ KIAD-KMCO.J 

♦ KIAD-KMCO.T 

♦ KIAD-KMCO.P 
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This naming convention enables modelers to make slight variations of routes on 
the basis of group aircraft performance, such as the distance the aircraft is allowed 
to fly out over water or how closely the aircraft must follow navigational aids 
(NAVAIDS) as opposed to flying direct. Our use of Potomac's route file engen- 
dered a few changes in input programming; for example, a route name must be 
assigned in the demand file by the programmer on the basis of aircraft type, which 
meant running a few lookup and write routines on all of our demand files. Other- 
wise, TAAM would assign the first route it saw to all aircraft traveling that city- 
pair; in this case, the “,J” route because it occurs first in the alphabet. We still had 
to define just as many STARs and SIDs. 

In Washington, all aircraft tend to use the same arrival and departure fix. In this 
case, the performance variables in the STAR and SID files were set to limit which 
aircraft opted for a particular SID or STAR. For instance, 

KI AD_0 1 R_ROBRT_ 1 .sta and KlAD_01R_ROBRT_2.sta are the STARs for jets 
and turbos, respectively, arriving to Dulles from the arrival fix Robert. In the first 
file, altitudes are set higher and the set of aircraft using the STAR is restricted to 
high-performance jets and turbos; all other aircraft use the second STAR, which 
has lower altitudes. 


Because we had to program almost all of our SIDs and STARs from scratch, we 
consolidated some arrival fixes; for example, all aircraft arriving to Kessel (ESL) 
always continue on to Armel (AML), so we eliminated Kessel as an arrival fix. 

We then searched the route file to write ESL AML KBWI on the ends of all 
routes that formerly ended as ESL KBWI. 

Airspace Routes 

We are indebted to the FAA’s Potomac Metropolitan Control Facility Planning 
Office for sharing Washington-Dulles TAAM program files. The Potomac office 
provided configuration advice, traffic counts, electronic airport runway layout 
files, some electronic SIDs and STARs, and instructions for executing the re- 
maining SIDs and STARs. 

Dulles operates in two basic configurations: south or north. It runs north approxi- 
mately 75 percent of the time. Dulles has two main parallel runways (01/19) that 
handle most of the traffic. In visual meteorological conditions (VMC), Dulles 
staggers jet departures and arrivals, with arrivals on one parallel runway and de- 
partures on the other. Turboprops arrive or depart on the overflow runway (12/30) 
and on one of the parallels, depending on whether there is an arrival or departure 
push; moreover, runway assignment varies with destination. Dulles is busy with 
alternating arrival and departure pushes all day; there are six arrival pushes and 
six departure pushes between 8:00 a.m. and 10:00 pm. For our study, we picked 
the north configuration, which in VMC means jet arrivals on 01R, jet departures 
on OIL, turboprop arrivals on OIL, and turboprop departures on 30. 
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Reagan National Airport operates either north or south and experiences the same 
winds as Dulles. In VMC, National takes arrivals on its main runway, 18/36, and 
on one or two crossing runways — 03 and 33 or 21, depending on winds. In the 
north configuration, jets and props are landing on 36, and props are landing on 33 
and 03. Jets depart 36, and turbos depart on 03. Figure 2-1 provides an illustra- 
tion; the shaded hexagons in the figure represent special-use airspace that is not 
open to commercial aircraft. 

Figure 2-1 . Washington Airspace Flows in VMC 



Through meeting and discussion, Potomac office personnel assisted us in model- 
ing air routes as close to reality as possible. Dulles’ easternmost runway’s air- 
space abuts airspace owned and used by Reagan National Airport. There is room 
for an arrival flow but not sequencing along the eastern side of the airport; that 
corridor is used during north operations. In terms of land use, the area west and 
south of Dulles is airport owned and undeveloped; there is a great deal of room 
for expansion — although the terminal is on the northeast end of the airport, which 
would make for a long taxi. To the east of the airport is a six-lane highway, as 
well as office space on the other side of the highway, including the FAA’s na- 
tional traffic management office (formerly known as the Central Flow Control 
Facility). To the north there is greenspace and then residential area. Leesburg Air- 
port. with a single runway, is located 7 miles to the northwest. 
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Current plans are for airspace changes to be made only every 5 years. Washington 
recently completed an airspace redesign study. The configurations depicted in 
Figure 2-1 should be accurate until about 2004. 

We did not validate the simulation setup against actual flight time and delay data. 


Creating Demand Files 

The Official Airline Guide (OAG) schedule published for June 12, 1997 was used 
as the basis of our traffic schedule. The schedule was increased slightly to account 
for unscheduled and general aviation operations traffic . 

The LMINET and TAAM demand files were derived from a common 
source — the 1997 OAG — and so schedule adjustments were passed from one 
model to another as schedule perturbations. The process is illustrated in Fig- 
ure 2-2. 


Figure 2-2. Iterating Intermodel Schedule Perturbations 


Output from LMINET: minutes of ori gin delay 


REVISEO ATL 

2.069 

BDL 

1.3873 

BOS 

2.0571 

CMH 

1.4286 

GSO 

^L2766 



Minutes of delay added to TAAM flight files; flights from ATL in 0600 leav 


e 2 minutes later, etc. 


UAL6156 BA14 
DALI 800 B757 
DAL 180b MD80 
VJA0004 DC 9 
DALI 880 B727 
VJA0014 DC 9 


1 KALB-KIAD.T 
1 KATL-KIAD.J 
1 KATL-KIAD.J 
1 KATL-KIAD.J 
1 KATL-KIAD.J 
1 KATL-KIAD.J 


240 01,19:20 01.20:27 0 OS 

400 01,06:37 01,07:54 0 OS 

370 01,06:37 01.07:55 0 OS 

370 01,09:05 01.10:24 0 OS 

400 01.10:20 01.11:37 0 OS 

370 01.12:20 01,13:39 0 OS 


TAAM reports out flight history. Minutes of delay per market pair are extracted. 


Delay 

Flight (Act-Sched) Route 
VJA0006 0:06:37 KATL-KIAD.J 

DAL0439 0:05:10 KATL-KIAD.J 

VJA0014 0:05:01 KATL-KIAD.J 

DAL2036 0:04:56 KATL-KIAD.J 

VJA0008 0:04:54 KATL-KIAD.J 




Minutes of delay are added to LMINET 
calculations and LMINET is re-run. 


REVISE1 BDL 

1 .8987 

BWI 

2.1352 

CLE 

2.4906 

DTW 

3.7177 

EWR 

3.4101 

GSO 

2.2581 

JFK 

2.0388 


As Figure 2-2 shows, LMINET is run for the nation, and origin airport delays are 
reported out. The origin airport delays in the first hour of flying are then used to 
perturb the TAAM flight file. TAAM is then run, and delays by market pair from 
TAAM are sent to LMINET and input as a more accurate picture of a locally 
modeled airport. LMINET is run again, and origin (airport) delays in the second 
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hour are captured and sent to TAAM. TAAM’s flights leaving in the second hour 
are delayed by the amount indicated by LMINET, and TAAM is re-run. The de- 
lays at the locally modeled airport in TAAM are reported back to LMINET by 
market pair again, and so on. 

Delay Comparison 

Once the integration was accomplished and the intermodel iteration begun, delay 
numbers came in. Ordinarily, delay numbers are the calibrating point of a model 
or model interaction. In this case, however, the models are very different; thus, 
the outputs are very different. We believe that none of the outputs can be com- 
pared. We cannot compare flight time to flight time because there are no individ- 
ual flights in LMINET. We cannot compare delay times at IAD. We also cannot 
compare nationwide delay figures because TAAM is not reproducing national 
delay figures in any measure that could be expected to reflect reality. 

The net effect of LMINET perturbations on the TAAM flight schedule was to in- 
troduce delays. In three separate periods during the day, ground holds were estab- 
lished for Boston arrivals; in one period there also was a brief ground hold for 
Seattle arrivals. Mostly, however, terminal delays created departure delays for 
flights bound to Dulles. Figure 2-3 shows the number of flights with departures 
perturbed by LMINET, by hour. The peak hourly number of perturbed flights was 
29, out of a total of 800 flights for the entire day. 

Figure 2-3. Number of Flights With Adjusted Departure Times, by Hour 



The departure delays, particularly the ground holds, sometimes were enough to 
push a departure from one hour into the next hour. Figures 2-4 and 2-5 examine 
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Integration of LMINET With a TAAM Plus Simulation Mo de l a t IAD 


arrival and departure demand in the TAAM simulation alone (dotted lines) and 
after the cumulative effect of LMINET-produced perturbations. 

Figure 2-4. Arrival Demand at IAD 


100 
90 
80 
70 

«2 60 
~cr> 50 
K 40 
30 
20 
10 
0 

0 6 12 18 24 

Hour 



TAAM alone 
LMINET+TAAM 


Figure 2-5. Departure Demand at IAD 



Although on first inspection arrival peaks appear to move back in time (are 
pushed earlier) in the LMINET plus TAAM simulations, this result is a kind of 
optical illusion; in fact, arrivals are pushed forward in time starting from 
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6:00 a.m., but they are pushed forward far enough that they appear to move 
backward. 

Because the ground movements (taxiways and gates) were not modeled in the 
TAAM simulation, the numbers depicted are truly departure demand and arrival 
demand. Because of ground congestion, it is unlikely — though possible — that the 
actual Dulles could achieve the peak arrivals and departures depicted. 

The differences between the dotted (TAAM alone) and solid (TAAM and 
LMINET) lines is the added delay imposed when NAS feedback with LMINET is 
included. The differences in departure time and arrival times from the TAAM- 
only run and the TAAM-LMINET integration are reproduced in Figures 2-6 and 
2-7. The measurements in Figure 2-6 were produced by sorting flights by (unper- 
turbed) departure time, then comparing the departure time of each flight (by flight 
number) in TAAM-only and TAAM-LMINET runs, and summing the differences 
for all flights departing each hour. 

Figure 2-6. Differences in Departure Time 
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Integration ofLMINET With a TAAM Plus Simulation Model at IAD 


Figure 2-7. Differences in Arrival Time 



The measurements in Figure 2-7 were produced by sorting flights by (unper- 
turbed) arrival time, then comparing the arrival time of each flight (by flight num- 
ber) in TAAM-only and TAAM-LMINET runs, and summing the differences for 
all flights arriving each hour. 

Total flight delays, sorted by hour of departure and arrival for TAAM alone and 
the TAAM-LMINET combination are given in Figures 2-8 and 2-9. 

Figure 2-8. Comparison of Total Departure Delays by Hour 
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Figure 2-9 . Comparison of Total Arrival Delays by Hour 
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Conclusions 

Previous simulations at Dulles revealed that the airport is very near capacity, and 
adding flights or changing the runway configuration can lead to disproportionate 
increases in delays. We see this behavior confirmed in the larger spikes in differ- 
ences in arrival time (Figure 2-7) over differences in departure time (Figure 2-6). 
Perturbations in the flight demand schedule from LMINET seemed to have the 
effect of further bunching peak traffic at Dulles and increasing delays, which 
probably is an accurate representation of the real impact of NAS perturbations on 
an otherwise balanced airport schedule. A more thorough examination of this ca- 
pability should include the ground movement component at Dulles and verifica- 
tion of pre-integration (i.e., TAAM only) flight times and delays. 
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Chapter 3 

Integration of LMINET with a SIMMOD Model at 
Chicago O’ Hare International Airport 


The purpose of this study was to demonstrate the feasibility of integrating 
LMINET and SIMMOD. This analysis of airspace and airfield performance was 
conducted using SIMMOD Plus and LMINET. The analysis simulated the 
movement of arriving aircraft from the entry point in the Chicago TRACON (ap- 
proximately 40 nautical miles from the airport) to a representative gate location 
and departing aircraft from a representative gate location to their exit from the 
TRACON airspace. The SIMMOD Plus and LMINET models produce output 
measures of aircraft travel time and delay. 

The city of Chicago recently completed a simulation analysis of the World Gate- 
way Program, which was the basis for a benefit cost analysis and supported 
ongoing environmental assessment of a proposed project at Chicago O Hare In- 
ternational Airport ([5]). The city of Chicago agreed to share its SIMMOD study 
for the purposes of this project. For this analysis, one primary good weather oper- 
ating configuration was selected from the city of Chicago s study. 


SIMMOD Model at Chicago O’ Hare 
International Airport 

The runway layout and varying wind and weather conditions at O Hare allow for 
up to 70 unique runway operating configurations. Historical analysis of runway 
use at O’Hare, using the Airport Noise Monitoring System (ANMS), revealed that 
there are four primary Visual Flight Rule (VFR) or good weather operating con- 
figurations and two primary Instrument Flight Rule (IFR) or bad weather operat- 
ing configurations. VFR conditions are defined as when the cloud ceiling is 1,000 
feet or greater and ground visibility is 3 statute miles or greater. IFR conditions 
are defined as when the cloud ceiling is less than 1,000 feet or ground visibility is 
less than 3 statute miles. 

Figure 3-1 illustrates the primary operating configurations at Chicago O’ Hare, 
along with the configuration utilization. Operating configuration Plan B, shaded 
in gray, was selected as the basis for this study. 
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Figure 3-1. Operating Configurations at Chicago O' Hare International Airport 
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Integration Process 

The LMINET simulation model and SIMMOD Plus model were run on one-hour 
time increments, starting at 5:00 a.m. local time. Information gathered from the 
LMINET model was used to determine the number of flights and which city pairs 
would be delayed into the Chicago SIMMOD analysis. 

The events (or schedule) file was modified on the basis of city pairs and delay 
statistics from LMINET prior to running the same hour through the SIMMOD 
model. This process was replicated 21 times throughout the day to ensure that all 
activity was captured. 

The LMINET model indicates which city pairs are being delayed into the Chicago 
area. This information is listed by departure time from the originating airport. For 
example, if a flight is delayed leaving Los Angeles, CA, at 8:00 a.m. local Cali- 
fornia time, it will be delayed arriving into the Chicago TRACON airspace ap- 
proximately 3>/ 2 hours later. A database was created that included flight miles that 
each city pair is located from Chicago. From this distance, an average flying time 
was calculated to determine exactly when the delayed flight out of Los Angeles 
would arrive in the Chicago TRACON airspace. This calculation was performed 
for all city pairs in the design day flight schedule that were delayed. 
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Integration of LMINET with a SIMMOD Model at 
Chicago O’ Hare International Airport 

In modifying the arrival time into the Chicago O Hare TRACON, it was impor- 
tant to make sure that if the flight was a through flight, the ground time remained 
representative of actual airline flight operations and that the departuie time was 
modified when necessary. A new event file (SIMU09) was created and run 
through SIMMOD. The output from the SIMMOD run was then used to run 
through LMINET, and the process was started over again. 

Following our general simulation model integration methodology outlined in 
Chapter 1, we will use delays reported at other LMINET airports to modify arrival 
times at ORD and the departure delay at ORD to modify arrival times at other 
LMINET airports. Delayed arrivals will induce delayed departure at ORD and other 
LMINET airports, which are taken care of automatically by LMINET. For the 
SIMMOD model at ORD, we have to manually modify the induced delayed depar- 
tures. The steps of the integrated LMINET-SIMMOD simulation are as follows: 

1 . Initialize LMINET and SIMMOD and load appropriate computer files, in- 
cluding schedule files, capacity and delay models, and the weathei file. Set 
the current time epoch to zero. 

2. Run LMINET, using the most current schedule file. 

3. Collect departure delays at other 63 airports at LMINET run. The depar- 
ture delay for a flight from a LMINET airport to ORD is assumed to be 
the average departure delay at that airport. 

4. Delay the arrival time at ORD by the amount of departure delay at other 
LMINET airports. 

5. The logic in this step applies to through flights only. If the ground time 
remains within 90 percent of the original ground service time, it is not 
modified. If the departure time falls to less than 90 percent of the original 
ground service time, it is delayed back to 100 percent of the original 
ground time as scheduled 

6. Create a new event file (SIMU09), based on Steps 4 and 5. 

7. Run SIMMOD, using the most current schedule file. 

8. Collect departure delay statistics at the end of SIMMOD run. The overall 
departure delay for the selected configuration is picked. 

9. Create a new schedule file LMINET run with delayed arrival time at other 
LMINET airports by the same amount of departure delays at ORD for the 
scheduled flights. 

10. Advance time epoch by 1. 
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1 1. Repeat steps 2-10; the integrated simulation ends once the time epoch is 
through 20. 

Because of the flight time, departure delays will only delay arrivals sometime 
later in the day. LMINET has a feature that reports the number of flights being 
“ground-delayed” — a phenomenon in which a flight may be forced to delay its 
departure at the destination airport because of an imbalance of arrival demand and 
airport capacity. Most ground delay programs enacted by the FAA are related to 
inclement weather. For the weather date selected (April 8, 1996), Boston issued 
the ground delay for a few hours in the morning because of bad weather there. 
Seattle and San Diego also issued a ground delay for a few hours. Although 
LMINET follows the same logic, its report of affected flights is at the time of 
scheduled arrival rather at the departure time. Thus, the modification of departure 
time at ORD because of the ground delay logic is retroactive. Because our event 
files are modified cumulatively, this retroactive modification does not have any 
impact on the simulation results at the end. 

Although 21 iterations theoretically are required, we end the integrated simulation 
after Epoch 1 7 because there is no schedule modification thereafter. 

Results Comparison 


Results of the simulation were compiled for each of the following alternatives: 

♦ SIMMOD only 

♦ SIMMOD-LMINET integration 

SIMMOD Only 

The initial simulation run was for SIMMOD only. Chicago O’ Hare International 
Airport Operating Configuration Plan B was run from 5:00 a.m. local time 
through 1 :00 a.m. local time the next day. The results of this simulation run are 
the basis for comparison with the output from the SIMMOD-LMINET integration 
simulation runs. 

SIMMOD-LMINET Integration 

Figure 3-2 presents delay and travel time statistics for the SIMMOD-only and 
SIMMOD-LMINET integration simulation runs. This table also compares the 
simulation results for both methodologies. Overall, there is a difference of 
0. 17 minutes per operation between the SIMMOD-only and SIMMOD-LMINET 
integration runs — a difference of approximately 1 percent. 
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Integration of LMINET with a SIMMOD Model at 
Chicago O' Hare International Airport 


Figure 3-2. SIMMOD-Only Versus SIMM OD-LM IN ET : 
Comparison of Performance Results 





The largest change of any of the performance measures was the departure ground 
delay; the change was 0.67 minutes per operation. The primary contributing cause 
of this reduction in delay could be flattening of demand throughout the delay as a 
result of delays incurred outside the Chicago area. As flights are delayed outside 
the Chicago system, they arrive into the TRACON airspace later than scheduled. 
This factor causes a flattening of the schedule and results in fewer delays. 


Figure 3-3 presents, in tabular format as well as graphically, the number of flights 
that were modified by hour for each hour of the simulation analysis. By the late 
evening hours, delayed arrivals had been reduced to a few flights. 
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Figure 3-3. Hourly SIMMOD-LM1NET Modifications 
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Integration of LMINET with a SIMMOD Model at 
Chicago O' Hare International Airport 

Except for some lengthy delays caused by bad weather at Boston and a few 
lengthy delays caused by bad weather at Seattle, most of the delays are small. 
Therefore, hourly demands are modified slightly, as illustrated by Figures 3-4 and 
3-5. 

Figure 3-4. Arrival Demands at ORD 
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Figure 3-5. Departure Demands at ORD 
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Figure 3-6 presents the daily average delay, peak delay hour, and daily delay and 
travel time totals for the SIMMOD-only simulation analysis. 

Figure 3-6. SIMMOD-Only Delay Summary 
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Integration of LMINET with a SIMMOD Model at 
Chicago O 'Hare International Airport 

Figure 3-7 illustrates the daily average delay, peak delay hour, and daily delay 
and travel time totals for the SIMMOD-LMINET integration analysis. 


Figure 3-7. SIMMOD-LMINET Delay Summary 
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Figures 3-8 and 3-9 depict arrival and departure delays at ORD for the SIMMOD- 
only and SIMMOD-LMINET cases. Overall, the delay and travel times, peak 
hour statistics, and daily delay totals are representative between the two simula- 
tion alternatives. The hourly delay curves of the two simulation alternatives are 
consistent, which is expected because their demand curves are close for arrival 
and departure demands at ORD. Nonetheless, we noticed differences especially 
a large average arrival delay at 20:00. We believe that this large difference is at- 
tributable to the small difference of demands at that time. Because the airport 
operates at close to its capacity, any small change of demand undoubtedly will 
lead to a large delay change. 


The value of the integrated SIMMOD-LMINET simulation is best manifested 
when demands are close to airport capacity. The peak demand time conesponds 
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to a large volume of passengers — especially business travelers, who are more sen- 
sitive to flight delay. The peak demand time also is the time when airlines and 
airport authorities pay the most attention to airport operations because it typically 
is the bank operation of a large hub of the airlines. Any delay at the bank opera- 
tion will have large repercussions on an airline operation because of the ripple 
effect. 


Figure 3-8, Comparison of Arrival Delays at ORD 
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Integration of LMINET with a SIMMOD Model at 
Chicago O 'Hare International Airport 

Figure 3-9. Comparison of Departure Delays at ORD 
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Chapter 4 

Future Work 


Under our proposed PAW approach (outlined in Chapter 1), we have demon- 
strated that we can integrate LMINET with TAAM and SIMMOD. Although the 
delays generated by TAAM and SIMMOD at IAD and ORD are similar before 
and after integration with LMINET, we do notice some considerable difference 
when the scheduled demand is close to airport capacity — a phenomenon that will 
appear more frequently in the future because of ever increasing demand and lim- 
ited capacity growth. Therefore, it is very important to conduct this kind of inte- 
grated simulation if one wants to analyze future air traffic performance, which is 
exactly the purpose of most simulation studies. 

The success of the feasibility study of LMINET integration with TAAM and 
SIMMOD leads us to believe that we can integrate LMINET with more TAAM or 
SIMMOD models in the network. TAAM, SIMMOD, or any other local air traffic 
simulation model can be linked through LMINET. If more TAAM or SIMMOD 
models are available, it would be possible to get detailed delay measurements for 
several major U.S. markets, such as the Northeast corridor, the Florida corridors, 
the Texas intercity airspace, the California interstate airports, and the Northwest 
corridor. 

Although the feasibility study was successful, it is not a full-blown simulation 
study. Based on our analysis and experience of running the integrated model, the 
following tasks should be carried out if a full-blown integrated simulation is con- 
ducted: 

♦ Automate the execution process. Collection of delays at other LMINET 
airports to the TAAM or SIMMOD airport and selection of delayed flights 
at TAAM or SIMMOD airports are automated. Collection of delay statis- 
tics in the TAAM or SIMMOD outputs is manual, as is the rest of the exe- 
cution of the models, although the models themselves are computer-coded. 
The process is laborious and, because many manual steps are involved, er- 
ror-prone. Thus, we first need some scripts to extract the right delay sta- 
tistics from TAAM or SIMMOD output. LMINET is best run by a high- 
end Unix workstation. Although SIMMOD can be run in Unix, it is best 
run on a PC to take advantage of its graphics interface. The TAAM license 
is very expensive, so it has been purchased at only a lew sites for Unix 
workstations. Thus, the script for the data transfer must work across com- 
puter platforms for a future integrated simulation. The second automation 
task is to send extracted delay statistics from one computer to another, 
which will likely be across platforms or across a local area network 
(LAN). The third automation task is to let each model— LMINET, 
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TAAM, SIMMOD, or any other simulation model — take delay statistics 
fed from other models and modify its schedule file. The last automation 
task requires a manager module that will carry the entire simulation with- 
out any human intervention. Essentially, the manager module will control 
the time clock and manage the execution of the simulation models and the 
data transfer from model to model. 

♦ Enhance TAAM and SIMMOD with the capability of “ warm start" or 
reading the schedule file record by record. “Warm start” will let the 
simulation with active flights instead of empty aircraft in the model. If we 
can use the system state at the end of the last epoch for the ones at the be- 
ginning of the current epoch, we can advance the simulation epoch-by- 
epoch without taking our PAW approach. If the models can be modified 
further to read the schedule records one by one, we can modify the sched- 
ule at any time when delay statistics from other models become available. 
We believe these two capabilities would be easy to implement by the 
TAAM and SIMMOD vendors. Each of these capabilities will enable us to 
abandon the PAW methodology and follow the original methodology 
without any repeated simulation runs, which will greatly enhance the 
speed of integrated model execution. The need for TAAM to have the 
foregoing capabilities is more pronounced because it takes a long time to 
run. 

♦ Develop an algorithm that can generate detailed future flight schedules 
and itineraries. Although we have demonstrated the feasibility and benefit 
of an integrated LMINET-TAAM and LMINET-SIMMOD simulation 
model, the ultimate success of an integrated simulation study must rest on 
the availability of the detailed flight schedule that TAAM and SIMMOD 
require. This is necessary because the simulation models are “what-if’ 
tools to analyze the air traffic system in an airport, a region, or the entire 
NAS. The most frequent use of the simulation studies is to analyze air traf- 
fic in the future under a forecast. The air traffic schedules required by 
TAAM and SIMMOD include detailed information about aircraft move- 
ments in time and place (as noted in preceding chapters), which can be 
constructed from published or observed schedules. Although air traffic 
forecasts are available at higher aggregate levels (e.g., national or airport 
level) from the FAA’s Terminal Area Forecast, the forecast of a specific 
flight schedule must be developed. To accompany LMINET, LMI has de- 
veloped an algorithm to forecast a flight “schedule” on the basis of the 
current schedule, airport traffic growth rates, and a set of airline operating 
strategies. Although this schedule’s information on origin and destination 
pair and departure and arrival hours is adequate for use with LMINET, it 

is not detailed enough for TAAM or SIMMOD. This schedule must be 
augmented to include accurate departure and arrival times up to the min- 
ute, equipment type, and flight tail number to designate the flight itinerary. 
Even with the aforementioned shortcoming, we believe that the LMI 
schedule forecast model can serve as a starting point for any schedule 
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Future Work 


forecast model to be developed because it is guided by a set of solid eco- 
nomic and operational principles [2, 3, 4]. If airspace delays also are de- 
sired in an integrated model, we must develop another model for flight 
routes under the ATM paradigm, weather conditions, and air traffic con- 
gestion. LMI already has developed a model to generate optimal flight 
routes under the Free Flight paradigm, which we believe can be adapted 
for TAAM or SIMMOD use. 

♦ Model LMINET time frames in shorter time increments than 1 hour. This 
methodology modification is related to the arrival and departure bank 
structures of individual airports. Currently, LMINET assumes 1-hour time 
frames and scheduled activity that is to occur during that hour. For exam- 
ple, there might be 60 arrivals scheduled for a particular hour. If that hour 
time frame is simulated, the airfield might be able to process all 60 arrivals 
with no delay. In the schedule, however, most of the 60 arrivals are sched- 
uled to occur during the first 15 minutes of the hour. This difference 
would affect the amount of delay incurred during the same hour using the 
same schedule. If LMINET were run based with smaller time frames, the 
delay might be captured — which is more representative of actual delays on 
a flight-by-flight basis. 

♦ Perform sensitivity analysis of simulations. Additional simulation runs can 
be performed to evaluate modifications of various input requirements for 
LMINET, TAAM, or SIMMOD. This analysis will lead to a better under- 
standing of the impact of simulation inputs on the delay analysis. For ex- 
ample, SIMMOD contains an on-time probability distribution that 
attempts to capture delays that are incurred outside of the Chicago area. 
LMINET is modeling 64 of the busiest airports in the United States and is 
delaying flights into the Chicago TRACON on the basis of acceptance 
rates and weather information from around the country. The presence of 
LMINET information might warrant removal of the on-time performance 
distribution because theoretically, delays outside the Chicago system 
already are being captured through LMINET. 

♦ Modify arrival and departure acceptance rates for each airport, depend- 
ing on anticipated activity. Airports such as Chicago O Hare International 
Airport have very dynamic runway use throughout the day. There is no 
specific number of arrivals and departures that can occur all day. When 
arrival demand warrants, a third, or triple, arrival runway can be used. 

This additional runway increases the acceptance rate of arrivals at the air- 
port but decreases the acceptance rate for departures. During the next 
hour, there might be a departure bank, and the triple runway could be used 
for departure operations. This operational strategy, in turn, would affect 
the arrival acceptance rate. Study of the arrival and departure banks could 
be used to determine when arrival and departure acceptance rates should 
be modified. 
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Appendix A 

Using TAAM 


This appendix contains a brief description of the TAAM model and some hints 
and instructions for a beginning user to begin to understand and use TAAM. 

Description of TAAM Model 


TAAM has four modules: the Interactive Data Input System (IDIS); the simula- 
tion engine (SIM); the Report Presentation Facility (RPF), which reports output; 
and Gtool, an input mapping program. 


Data Input 

TAAM software is delivered with a supply of data files that the user may use to 
begin modeling. These data files provide a useful starting point for general mod- 
eling questions — such as, by what function do airspace conflicts increase as traffic 
increases? To increase the accuracy of the simulation, however, provided files 
should be perfected or a custom simulation created. 

IDIS guides the user through creation or editing of several essential classes of 


files: 


♦ 

Airports 

♦ 

Waypoints 

♦ 

Routes 

♦ 

Timetables 

♦ 

Maps 

♦ 

Project file. 


In addition to the foregoing list, several data files that are not accessed through 
IDIS also are essential to the simulation: 

♦ The aircraft performance file 

♦ The aircraft cross-walk file (which equates aircraft with similar perform- 
ance characteristics to a single performance model) 

♦ The conflict resolution strategy file 
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♦ The sector separation setting file. 


The distinction between the first list and the second list is that the files in the first 
set have an obvious user interface; in effect, the model prompts the user to update 
those classes of files with each simulation. The files in the second set are in text 
format but have to be edited with a text editor; there is no built-in interface from 
IDIS to view or edit them, and there is no explicit mention of their use in the proj- 
ect file. Many beginning users remain unaware of the influence of the second set. 

In the following section, we discuss each class of data file by functions. 

IDIS-Definable Files 

Airport File 

The airport file lists the location of every airport in latitude, longitude, altitude, 
and magnetic deviation. It is used to stake out the points in three dimensions for 
aircraft objects to fly to. Creation of the airport file allows the user to model 
ground layouts of the listed airports. Every airport listed in the overall airport file 
is treated as a point airport unless the modeler specifies a ground layout for that 
airport. Once an airport’s ground layout is added to a project, the user would find 
additional data classes available under each airport, as illustrated below. These 
additional data classes can be filled in by the user. 

♦ Airports 

>• Airport list file, often called “Master. APT” 

► KATL 

■ Layout 

■ SIDs 

. STARs 

■ Usage 

> KIAD 

■ Layout 

. SIDs 

■ STARs 

■ Usage 
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> ... 

A layout file is a digital map of the airport surface; it can include runways, taxi- 
ways, aprons, de-icing stations, gates, buildings, and obstructions. The layout is a 
visual backdrop for the simulation; it also provides programmed routes for aircraft 
to travel on the ground. 

A Standard Instrument Departure is a defined route or procedure that a pilot fol- 
lows after takeoff and before entering en route airspace. Every runway generally 
has several SIDs, depending on weather conditions, aircraft climbing capabilities, 
and the desired direction of flight. In TAAM, each SID is programmed in as a 
separate file. 

A Standard Terminal Arrival Route is a defined route or procedure that an aircraft 
follows when it is entering a terminal airspace. Although the aircraft remains un- 
der the control of an air traffic controller, the STAR provides standard guidance 
for approaching the destination airport. Generally, each runway end has several 
STARs — one for each arrival fix in VMC and in IMC, often with variations in 
altitudes for higher- or lower-capability aircraft. In TAAM, each STAR is pro- 
grammed in as a separate file. 

Waypoint File 

The waypoint file contains the locations, names, and capabilities of the radio bea- 
con navigational aids (NAVAIDS) that most U.S. aircraft still use to define, plan, 
and track their flight route. The waypoint file also contains user-defined way- 
points which may correspond to points on arrival patterns, a turn onto a radial 

from a NAVAID, or arbitrary points. In TAAM, the NAVAIDs in the waypoint 
file are referenced by the route, STARs, and SIDs files. 


Route File 

The TAAM route file contains lists of waypoints that define connect-the-dots 
routes for aircraft to fly along. Routes can be radionavigation-limited — like the air 
traffic control (ATC)-preferred jetways and vectors (i.e., encompass a route that 
requires the aircraft to always have at least two radionavigation beacons within 

range) or they can be “great circle” between the destination and origin airports. 

Artificial waypoints can be easily created to reflect permutations, combinations, 
and variations on point-to-point and great circle routes. 

Timetable 


The timetable file— also called a flight file— is the file in which a modeler usually 
has the most interest; it is the “event” or “demand” file equivalent. The flight file 
lists, at a minimum, the flights that are flying, the day of flight, the time, the alti- 
tude, the origin and destination, and the type of aircraft. At its most detailed, the 
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file also lists the route taken, the altitudes en route, the SID, the STAR, and the 
runways used. 


Map Files 


Map files are computer aided design (CAD)-generated pictures that show func- 
tional structures and terrain features. The airport layout file is a map file. Points in 
map files are defined by latitude and longitude or by relative position to lati- 
tutde/longitude-defined points. TAAM mosaics all of the user-selected map files 
together into a single view. Common map combinations include coastlines and 
waterlines, air traffic control sectors, airport layouts, and state or political bound- 
ary lines. Map objects can be filled in or colored so that the TAAM simulation 
resembles an iconographic animation of traffic. 

Project Files 

Each simulation project is delineated by a project file, which tells the TAAM 
simulation engine which data files to read into memory to run the desired pa- 
rameters through a simulation. The format of the project file is a text list of the 
user-defined (via IDIS) data files, prefaced by a directory pointer relative to the 
TAAM home directory. Figure A-l shows a sample project file. The TAAM 
home directory is “home/taam.” 

Figure A- 1 . Sample Project File 

# single_terminal 

# data/map/gtool 
globe_new . pol 
zdcsecs . pol 
zbwsecs . pol 
znysecs . pol 

# data/map/3d 

# data/wpt 
master . WPT 

# data/apt 
master . APT 

# data/apt /KBWI/ layouts 
KBWI .pol 

# data/apt /KBWI / sids 
KBWI_33R_EMI_1 . sid 
KBWI_28_EMI„1 . sid 


Every simulation is governed by its project file. Multiple projects can reference 
the same files, and a multitude of projects can be easily created by changing the 
file selection of a project. For example, a user may build a simulation and define 
five different timetable files, corresponding to five different traffic connection 
strategies for a hub. Each simulation would have a project file that references the 
same master airport list, the same terminal layout, the same SIDs and STARs, and 
the same maps and waypoints but points to different traffic files. Having separate 
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project files for five different timetables allows the user to make similar changes 
to all projects at the same time (by changing a single file such as the waypoint 
file) and to re-run all alternatives in batch mode. 

Files that are essential to the TAAM simulation but are not defined or edited 
through the IDIS interface are not listed in project files. We refer to these files as 
“secondary" files. 

Secondary Files 

Aircraft Performance And Cross-Walk 

The flight performance file contains the minimum, average, and maximum speeds 
and fuel burns for hundreds of aircraft at altitude increments of about every 
3,000 feet. Performance characteristics are differentiated by phase of flight; 
climbing, cruising, descending; and rates of turn, rates of climb, and taxi and 
takeoff speeds. 

Conflict Resolution Strategy File 

The conflict resolution file is a set of 38 conflict resolution rules that TAAM con- 
sults when it detects a conflict. The resolutions are situation-specific; one may 
state, for example: 

If aircraft 1 is cruising and aircraft 2 is cruising and aircraft 1 is 
approaching from behind at the same altitude, then: 

1 . aircraft 1 speed up and head right 15 degrees 

2. aircraft 2 slow down and aircraft 1 head right 15 degrees 

3. ... 

4. ... 

5. ... 

then return to flight as planned. 

TAAM searches the list of resolutions until it finds the conflict described in 
clause 1, then applies the solutions suggested (here, nine possible ways to resolve 
the conflict) until the conflict is resolved. If the conflict is not resolved, TAAM 
continues to read the tde for additional strategies and tries other conflict resolu- 
tion strategies. 
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Sector Separation Setting File 


The sector separation settings usually are set when an air traffic sector is created 
in Gtool. The separations are stored in “*.sec” files. 

Magnetic Deviations, Improved Conflict Resolution, Integrated Noise 
Model 


Other files that could be important to terminal modeling but are not essential to 
this project are the U.S. magnetic deviation table, an improved conflict resolution 
file, and the Integrated Noise Model. The U.S. magnetic deviation table lists the 
magnetic deviation of magnetic north to true north that all aircraft must compen- 
sate for in setting courses. There is a table in TAAM where the user may fill in 
U.S. magnetic deviations. This table must be either completely filled in or com- 
pletely blank to affect the modeling simulation uniformly. The magnetic deviation 
is important only in vectoring instructions that might be contained in STARs, 
SIDs, and user instructions during the simulation. Once the user has started down 
this path, he or she cannot change his or her mind and input the magnetic devia- 
tion table without rewriting the SIDs and STARs. 

Improvement of the conflict resolution file can be accomplished by creating new 
conflict situations and adding new solution suggestions to the existing 38 situa- 
tions. Other users have done this with great result. The preferred method is to sit 
down with certified controllers watching the TAAM simulation and take note of 
the controllers’ expression of how they would resolve conflicts that TAAM en- 
counters. 

The Integrated Noise Model would determine the noise footprint left by virtual 
aircraft over virtual neighborhoods. In this simulation, approach paths are con- 
structed to avoid noise incursions, and TAAM aircraft do not stray from their as- 
signed paths. 

User Input Data and Data Necessary to Run 

The file that usually is of most interest to the modeler is the flight file, or the list 
of flights. This file is selected or programmed by the modeler to frame the prob- 
lem being studied. Regardless of the model used, in simulation studies the event 
file generally does not come as part of the model. To run a simulation in TAAM, 
the user must first have an aircraft performance file and a flight file. One of these 
files tells the aircraft how to fly; the other supplies the event aircraft. In this sim- 
plest of all simulations, the user could program an aircraft flying aimlessly around 
empty space. Add the airport file, and the aircraft can fly to and from points in 
that space. With the waypoint file and the route file, the user has the ability to 
make complicated or realistic flight routes. With the conflict resolution file, the 
aircraft avoid collisions as if they were being controlled by air traffic controllers 
today. Add maps, and the model begins to look like the airspace above the United 
States. 
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Additions to this basic file set are the prerogative of the analyst running the 
model; such modifications are added to increase accuracy in specific areas. Air- 
port points can be turned into airports with ground layouts. Airport layouts in- 
clude runways, taxiways, buildings, aprons, gates, and holding aprons; they often 
are used in TAAM simulations to help capture ground congestion effects at busy 
airports, which may affect departure delays. The airport layout can significantly 
increase the realism of the simulation. Airport layouts in TAAM also have been 
programmed to solve ground movement problems. 

Nonprecision approaches can be programmed as STARs. STARs are essential to 
TAAM for sequencing. If programmed STARS are not available, TAAM will 
build its own classic trombone-shaped approaches. Although this procedure will 
accomplish sequencing, it will not represent the airspace as it ordinarily is flown. 
Sequencing should be considered essential in any simulation in which timing and 
delays are regarded as important. 

Noise abatement procedures also are implemented in TAAM, via programmed 
SIDs and STARs that comply with noise abatement procedures. 

TAAM sequences aircraft only when aircraft are in controlled airspace. Air traffic 
control sectors also are used to set minimum separations and to impose flight re- 
strictions such as mile-in-trail sequencing methods. Although most U.S. en route 
airspace sectors were delivered with TAAM, there were some blank spots. Instead 
of filling the blank spots, it may be more expedient to develop a single “super- 
sector” — one sector that covers the contiguous United States to several miles out- 
side its boundaries, rising from 18,000 feet to 60,000 feet. This supersector 
ensures that aircraft will be within controlled airspace throughout the en route 
phase of flight at a minimum of effort. 

TRACON sectors can be drawn from individual sector position maps and from a 
terminal controller projection plate. These items generally are traced out in Gtool 
and then named, subsector by subsector. TRACON supersectors can be drawn in 
to ensure that the local area aircraft were always in positive control areas in 
TAAM. Again, these supersectors are time-saving innovations to create a work- 
able model, using minimum memory, without sacrificing accuracy of flight time 
and flight path. 

Modeling in fast time always involves trade-offs — in particular, the trade-off of 
accuracy of inputs versus time allotted to model — which is why we list minimum 
modeling requirements first. Other inputs we made to increase the accuracy of the 
model for this particular simulation include changes in the flight performance 
files for aircraft (as explained above); new waypoints to establish conga-line ap- 
proach paths and to demarcate turning points on SIDs; the very detailed flight file 
(which we discuss below); and airport usage files. 
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Airport usage files tell TAAM which runways are in use for different types of air- 
craft or different airlines, as well as whether they are open for arrivals and/or de- 
partures; whether tromboning on approach is allowed; decision thresholds for 
sequencing to a terminal; when to cross active runways; which taxiways are in use 
and by which aircraft and which airlines; where the holding aprons are; which 
taxiways are high-speed turnoffs; which aircraft use which STARs, SIDs, and 
runways; and where to de-ice and activate the noise model. For example, to model 
the fact that all Newark arrivals from Chicago take the PENNS standard ap- 
proach, the user would write a rule that is contained in the airport usage file. Air- 
port usage files are extremely important in terminal simulations because they 
control the decisions of the aircraft as they enter sequencing, approach, and 
choose a runway, land, and taxi to the gate. 

Tasks to Complete a Project: Flight Files, 

Running the Model, and Debugging 


As TAAM loads the airspace information files noted above, it creates an error 
file, sending error messages to the screen and a file. The screen alert can be turned 
off, if desired. 

STARs and SIDS 

STARs and SIDs should be programmed and loaded for the runways in use that 
day. Initially, STARs were programmed in from standard approach plates that 
pilots use to fly the approach. During testing, these “by-the-book” approaches 
should be calibrated in extensive discussions with local approach controllers. 
Textbook approaches start in the en route airspace, and the approaches listed do 
not cover all possible influxes of traffic; traffic often “joins” a STAR in progress. 
During peak periods, approach paths can turn into long, snaky conga lines that are 
characterized by numerous vectors. Working with the TRACON controllers, the 
user can enter new approaches. Template STARs can be customized to allow 
vectoring at certain points, resetting of the start of the STAR, and programming in 
vectors that controllers give to pilots orally, at the point where approach plates 
state, “ expect vectors to final.” 

Unfortunately, only one of these approaches will be used by TAAM during 
simulation: waypoint_l. The present version of TAAM simulation does not select 
multiple STARs from the same waypoint. This limitation is unfortunate because 
of the changing nature of the traffic flow and possible vectoring over time. In ad- 
dition, only one altitude can be set for each STAR. In the present version of 
TAAM, to depict jet and prop flows with varying vectoring or with complete al- 
titudinal accuracy, we would have to create one STAR for each option (e.g., 
COATE_JETS_ 1 ) and multiple routes to feed the STAR (e.g., KIAHKEWR_CJ 1 , 
KATLKEWR_CJ 1 ...), and specify the route for each flight to take in the flight 
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file. For a large simulation, a preprocessing tool such as a data-manipulating Java 
script or C++ program would have to be utilized. 

SIDs do not have a sequencing function. SIDs are necessary to prevent aircraft 
from going into free flight upon rotation (lift off) at the runway and to keep air- 
craft flying routes that represent reality. 

SIDs also are the only data that cannot be written in standard text and copied into 
a Unix file because they consist of encoded numerals and symbols. All other 
TAAM files can be created as text files and copied into the proper file. This setup 
often saves time over the data input system provided by The Preston Group (TPG) 
(i.e., IDIS), which is easy to use but time-consuming on extremely large simula- 
tion projects. 


Airports 

Airport layouts are one of the most prolific sources of bugs in TAAM because the 
airport layout can be very complex. Often, a programmer must spend a day sim- 
ply erasing programming kinks in the taxiways and gates, identifying aprons and 
connecting taxiway centerlines. In this simulation, the airport layout will be 
checked to ensure that aircraft are not landing on closed runways; that they are not 
overshooting open runways; and that they are achieving the rate of acceptance 
dictated in the terminal and airport usage files. The aircraft should be acquiring 
the user-input STARs and not building default approaches; they also should be 
tromboning automatically for sequencing. 


Waypoints 

Holding waypoints must be designated for airports of interest. TAAM will set its 
own holding waypoints if the user does not enter sufficient holding waypoints. 
One of the known bugs in TAAM involves holding waypoint selection: Aircraft 
sometimes choose their own holding waypoints or enter multiple holds. This bug 
is the subject of a multi-year improvement project at TPG. Debugging duties 
should include watching the simulation to see that aircraft are holding at the des- 
ignated waypoint and that the right number of aircraft are put into holding in 
comparison to baseline data. 

Debugging Flight Files 

In debugging, the true limits of the data in terms of accuracy, data drops, ger- 
maneness, and completeness are discovered. Debugging consists of two types of 
examination: one a statistical and commonsense perusal, the other to ascertain 
whether the data produce the flights that the analyst intended, in the time and 
manner intended. TAAM provides a helping hand on the second by providing er- 
ror messages as flight files are loaded to the simulation project. 


A-9 


For this type of simulation, in which data on flights flown and planned are loaded, 
TAAM provides a reasonableness check on the data themselves. TAAM delivers 
warnings when the position reports of aircraft are not within the parameters of the 
flight performance file. The analyst is alerted to the problem and can then use in- 
dependent verification to determine whether there is an error in the data or the pa- 
rameters of the flight performance file should be adjusted. TAAM also creates an 
alert when there is an unknown destination in the route file; the analyst can then 
check to see if the waypoint or airport was misspelled, the file used the wrong 
identifier, or a new waypoint must be added to the file. 

TAAM checks the performance of aircraft on STARs and SIDs: Turbo props may 
be attempting to take STARs designed for jets; clunky jets may be taking a STAR 
or SID meant for nimbler jets. These errors can be corrected by changing the us- 
age file to assign certain aircraft to certain STARs (the most accurate solution); 
relaxing the turn or altitude requirements on a STAR (a work-around to undertake 
with caution); changing the type of aircraft (a work-around that ignores those 
jets); or, in the case of overrun runways, adjusting the parameters of the aircraft 
performance file (to be done in delay studies but not in new-runway capacity 
studies). 

TAAM varies the weight characteristics of the aircraft in the simulation; the vari- 
ance is enough to prohibit B767s from landing on the shorter (outer) runways at 
Atlanta’s Hartsfield and heavy aircraft from landing at National Airport — although 
in reality such aircraft do so all the time, having been properly weighted. TAAM is 
not programmed to assume that airlines will adjust the weight of a widebody to 
land at a short runway. TAAM assumes average weights and performances. 
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SIMMOD Simulation Model 


SIMMOD Modeling Methodology 

SIMMOD Plus is a discrete-event simulation model that calculates various air- 
craft delay and travel time performance measures for airspace and airfield design 
projects. SIMMOD has been under development since the 1980s. Initially devel- 
oped as a fuel burn model, it has evolved into a comprehensive planning tool for 
airport designers, airport managers, air traffic planners, and airline operational 
analysts. The SIMMOD Plus model can be used to evaluate any number of alter- 
native airspace and airfield projects. Modeling can be used to support various air- 
space and airport studies in the development of cost-benefit analysis, environ- 
mental impact statements, environmental reviews, and master plan updates (to 
name a few). Through the past couple of decades, models of this type have gained 
acceptance in the aviation industry as an integral part of any type of analytical 
study. 

Although no two SIMMOD studies are exactly alike, there are general character- 
istics that all have in common. The first step in a SIMMOD study is to have a 
thorough understanding of the airport environment. This environment includes air 
traffic control procedures, runway operating procedures, and taxiway movements. 
To obtain this knowledge of the airport environment, a trip or trips may have to be 
made to the airport to interview air traffic controllers and airport operations per- 
sonnel. The input to the simulation model is created through this process. These 
procedures are transformed from the real-world operation to the simulation 
model. After the simulation model has been developed, the model is run. As the 
model is running, it is calculating many aircraft performance measures. These 
statistics are stored and presented at the end of the run in the form of delay and 
travel time statistics. 

SIMMOD Input/Output Files 

SIMMOD Plus has a series of input and output files in text or ASCII format that 
can be easily manipulated through the use of text editor programs. There are many 
input and output files from the SIMMOD Plus model; in this section, we briefly 
describe the primary input and output files that are used during a simulation 
analysis. 
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Input data for the SIMMOD Plus model is contained in separate files that repre- 
sent different areas of operation, including an airspace file, a ground file, and an 
events (or schedule) file. We used the city of Chicago’s World Gateway Program 
Airside Simulation Analysis for Chicago O’Hare International Airport Operating 
Configuration Plan B as the basis for this study. Each input file contains a series 
of specific data related to the airspace, ground or schedule. Numerous probability 
distributions are included which represent possibilities that may occur with human 
interaction between air traffic controllers and pilots. Each file is briefly described 
below. 

Airspace File 

The airspace file (also referred to as the SIMU03 file) includes detailed informa- 
tion concerning aircraft movements while in flight. Although there are too many 
details to list here, examples of information included in this file include, but are 
not limited to the following: aircraft route information, aircraft separation distri- 
butions, aircraft speed distributions, runway coordination information, and on- 
time arrival and departure distributions. This file was not modified during the 
study. 

Ground File 

The ground file (also referred to as the SIMU07 file) includes detailed informa- 
tion concerning aircraft movements on the ground at Chicago O’ Hare Interna- 
tional Airport. As with the Airspace File, there are many different types of 
information included in this file. Examples of data contained in this file include 
taxiway speeds and direction of travel, aircraft gate utilization assumptions, land- 
ing and takeoff roll probability distributions, and runway crossing probability 
distributions. This file was not modified during the analysis. 

Events (Schedule) File 

The events file (also referred to as the SIMU09 file) includes detailed information 
concerning scheduled and nonscheduled aircraft activity for a 21 -hour time period 
at Chicago O’ Hare International Airport. Examples of information contained in 
this file include the airline name, aircraft type, arrival time, departure time, and 
gate assignment. This file was modified, hour by hour, throughout the process. 


Report File 


Output data from the SIMMOD model is contained primarily in one file (the Re- 
port File), although various other files are used during the debugging process. The 
focus of this report, however, is on the information contained in the Report File. 
The Report File (also referred to as the SIMU48 file) includes summary output 
information from the SIMMOD Plus model. Information contained in this file in- 
clude but are not limited to the following: hourly runway use for arrival and de- 
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parture operations, average travel time by hour for each runway, average delay by 
hour for each runway, gate utilization statistics by hour for each gate, and flight 
delay information by 5-minute time periods for arrival and departure operation. 
We used information from this file in the comparison of the SIMMOD-only ver- 
sus the SLMMOD-LMINET integration analysis described in Chapter 3. 

Practical Issues of Running SIMMOD 

Undertaking a SIMMOD analysis can be a very time-consuming and costly proc- 
ess. The SIMMOD model itself is available through the FAA at a small cost. Pre- 
and post-processing tools that simplify the process somewhat are available from 
AT AC Corporation; these tools are packaged as SIMMOD Plus. 

Once the user acquires the software, the user must obtain appropriate hardware 
that will be able to run the model. The SIMMOD Plus model can be run on an 
IBM-compatible desktop or laptop computer. The following sections list the 
minimum and recommended IBM Desktop PC-compatible configuration and the 
recommended laptop configuration. 1 

Minimum Desktop Configuration 

♦ A 90 MHz Pentium processor 

♦ 32 megabytes of RAM 

♦ CD-ROM drive (speed not important) 

♦ A 500 megabyte hard drive (SIMMOD Plus with executables and default 
data files requires approximately 50 megabytes of disk space) 

♦ A monitor capable of displaying 800 by 600 pixels (SIMMOD Plus sup- 
ports higher resolutions, if available) 

♦ An average graphics card that has 1 megabyte of RAM and can support 
65,000 or more colors. 

Recommended Desktop Configuration 

♦ A 200 MHz Pentium processor 

♦ 64 megabytes of RAM 

♦ CD-ROM drive (speed not important) 

♦ A 1 gigabyte hard drive 

1 These specifications are based on intormation that is available on AT AC s Web site de- 
scribing SIMMOD Plus (<www.atac.com/plus/harware.html>). 
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♦ A monitor capable of displaying 800 by 600 pixels 

♦ A good graphics card that has 4 megabytes of RAM and can support 
65,000 or more colors 

♦ Windows NT version 4.0 (Windows 95 works well, although Windows 
NT is more stable). 

Recommended Laptop Configuration 

♦ A 133 MHz Pentium processor 

♦ 32 megabytes of RAM 

♦ CD-ROM drive (speed not important) 

♦ A 1 gigabyte hard drive 

♦ A monitor capable of displaying 800 by 600 pixels 

♦ A good graphics card 

♦ Windows 95 (Windows 95 has several laptop “user-friendly” options that 
make it a better choice for the laptop than Windows NT). 

Once the model has been installed on a desktop or laptop computer, the study can 
begin. The process can take many months, depending on the number of airport 
operating configurations to be modeled and how many alternatives will be evalu- 
ated. Before any alternative can be evaluated, the SIMMOD model must be cali- 
brated with actual airline performance statistics. This calibration will guarantee 
that the model is producing results that are representative of actual airline opera- 
tions. This process may involve meeting with air traffic controllers to get an accu- 
rate understanding of the airport environment. The calibration process itself may 
take 4-6 weeks or longer; the study itself also may take 4-6 months or longer. 

Delay and Travel Time Comparison 

We assembled and compared aircraft performance statistics for each of the 
SIMMOD-LMINET combinations modeled. These statistics allow for a compari- 
son of airfield and airspace alternatives. 

♦ Arrival Airspace (Air) Delay: Airborne arrival delay including delay 
caused by congestion outside the ORD TRACON, capacity constraints at 
ORD, and approach control delay incurred within the ORD TRACON. 

♦ Arrival Ground Delay: Delay incurred between the runway exit and the 
gate as a result of aircraft traffic congestion and runway crossings. 
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Appendix B: SIMMOD Simulation Model 

♦ Arrival Unimpeded Travel Time: Travel time from touchdown to the gate, 
based on distance and speed. 

♦ Total Arrival Time and Delay: Time computed as the sum of arrival air- 
space delay, ground delay, and unimpeded travel time. 

♦ Departure Airspace Delay: Airspace delay incurred as a result of conges- 
tion or outbound vectoringwhile merging onto the assigned departure track 
and prior to exiting the ORD TRACON airspace . 

♦ Departure Ground Delay: Delay incurred between the time an aircraft is 
ready to taxi from the gate and the time the aircraft reaches the departure 
queue. Departure ground delay includes gate push-back delay, delay 
caused by runway crossings, and delay caused by aircraft traffic conges- 
tion. 

♦ Departure Queue Delay: Departure delay incurred in the departure run- 
way queue as a result of separation minima, miles-in-trail restrictions, 
mixed runway operations, and intersecting or parallel dependent opera- 
tions, while awaiting departure clearance. 

♦ Departure Unimpeded Travel Time: Travel time from the gate to lift-off, 
based on distance and speed and route traveled. 

♦ Total Departure Time and Delay: Time computed as the sum of departure 
airspace delay, ground delay, queue delay, and unimpeded taxi time. 

Statistics also were reported for each time and delay category defined above, as 
follows: 

♦ Daily Average Delay and/or Travel Time: Average delay and/or taxi time 
(in minutes) incurred by each aircraft operation during the period. 

♦ Daily Total Delay and/or Travel Time: Total delay and/or taxi time (in 
minutes) incurred during a day, based on the number of operations in the 
design day flight schedule and the daily average taxi time and/or delay per 
operation. 

♦ Peak Delay Hour: Hourly average delay and/or taxi time incurred by each 
operation during the peak delay hour. 

Aircraft throughput statistics also were calculated and are defined as follows: 

♦ Peak Hour Arrival Throughput: Largest number of arrival operations oc- 
curring during a single hour. 

♦ Peak Hour Departure Throughput: Largest number of departure opera- 
tions occurring during a single hour. 
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♦ Peak Hour Operations Throughput: Largest number of arrival and depar- 
ture operations occurring during a single hour. 
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